The Year 2000 problem has been well documented for nearly two decades. Much of the existing business software was not designed to anticipate, and function during, the transition to the 21st century. Early in the dawn of the computer era, storage was at a premium and, as a consequence, two positions were rarely "wasted" by storing the number of the present century. Few programmers realized then that these early programs, and their descendants, would survive until the Year 2000.
Although the cause of the problem seems simple--the software only allows for two-digit years--the solutions currently available are anything but simple, and the implications of failure can be enormous. Certain industries, including banking, insurance, and health care, are particularly sensitive to dates. According to industry sources, the projected cumulative costs for most corporations to correct the problem falls into a range of $4 to $40 million dollars per corporation. Effort projections can be equally alarming. Some estimate that the total costs related to the "Year 2000 Problem" will be nearly $600 billion.
According to some experts, those who wait until 1998 to start the repair work will only succeed in correcting 60% of the problems. Companies may suffer irreparable damage. Although there are programs in place to provide services to help clients redevelop their application portfolios, there is a considerable risk that the available collective resources will not suffice.
Some solutions attempt to expand a two-digit year field to four digits. This simple change can introduce a host of associated problems such as: (1) file expansion, requiring additional storage, truncation, misalignment, performance impacts; (2) multi-system integration, introducing the necessity of coordinating changes across all systems that have interfaces or share files; (3) redevelopment timing, whenever systems changes will need to be synchronized to the change of century; (4) transitional logic, in which extra logic is needed to bridge between changed and unchanged applications; (5) timing logic, in which extra logic will be needed to handle the timing of switching to the Year 2000 changes.
Because of the effort involved in the year field expansion approach, other techniques employ procedural "work-arounds" to the problem. One technique involves logic that assumes that the century has changed if the year value falls into a specified range. However, not only does this approach tend to work for a limited time, it typically must be conditioned to the context of the specific date field. Dependencies often exist between databases, programs, procedures, and libraries, which must be identified and corrected. Accommodations also should be made for other problems such as sort logic, table searches, key matches, etc. Such approaches may introduce extra logic that is difficult to understand and, consequently, to maintain.
Ideally, a solution to help with this problem would reduce the overall effort required by reducing or eliminating many of these associated difficulties that are now being encountered.
What is needed then is apparatus, methods, and a computer program product for revising a field in computer program code that effects the change within the constraints imposed by a storage attribute. Furthermore, there is a need for intelligent code revision in which the effects of a particular code revision upon other portions of the code are identified and analyzed. If additional changes are indicated then the other revisions are made. Such apparatus, methods, and product would be particularly useful in resolving certain facets of the "Year 2000" problem in that existing code can be analyzed and revised to obviate code failures induced by the advent of the new millenium.